Knowledge - Based Support of System Analysis for Failure Mode andE ects

failure relationship Figure 6: Fault tree for the failure plugged up of a Filter. Wifa supports a user mainly by providing comfortable access to FMEA cases. She or he can, for example, retrieve actions that have been taken for similar failure modes. 4.7 Completeness and Consistency of System Description The goal of a system description should be to include everything that is of practical relevance in a correct and consistent way. Of course, it is impossible for a software system to know what is practically relevant. A software system can only manipulate information that is entered in a given formalism. Thus, the notion of completeness depends on the formalism and the inference mechanisms. Di erent formalisms allow di erent approximations of correctness and consistency. A conventional form-based FMEA is complete if for any component appearing in the form all other columns of the form are lled. There is no way to discover con icting entries. In Wifa an FMEA is complete, if there exists a complete system structure, a complete fault tree, and a complete form. A system structure is complete, if each system element has at least one function, and all function participants of all functions are system elements. A system description is consistent if the following conditions hold. All function participants are compatible9. 9Compatible means that all function participants belong to the same or a more speci c system type speci ed in the corresponding function type. Given a function F1 at a system Ss. If the goal of an output ux FL of F1 is a system element Sg then Sg must contain at least one function the input ux of which is FL and the source of this ux is Ss. For each ux of a subfunction one of the following conditions must hold. The ux of the subfunction { is a function participant at the super function, { is a more speci c ux of a ux of the super function, { is a part of a ux of the super function. Furthermore, for any function type there can be additional speci c consistency conditions. For instance, the function transmit requires input and output ux to be identical. A fault tree is complete if all failure modes listed in the system description are linked to other failure modes. A form in Wifa is complete if all columns are lled with entries of the proper type. These completeness and consistency conditions do not guarantee that everything of practical relevance is consistently described. However, Wifa is much closer to this objective than conventional form-based FMEA. 5 RELATED WORK Wifa is not the only system that tries to improve conventional FMEA. In the following, two related projects are introduced and points out their respective aims are pointed out, how they approach these aims, and where the di erences with respect to the aims and the approach to Wifa are. Pfeifer et al. [10] describe a simple case-based approach to support an engineer during an FMEA session. Their system Inquass-Fmea accesses a case base of old FMEAs to present a list of possible components and processes to the user from which she or he can copy information to the current FMEA. During an FMEA the user must assign one type of the hierarchy of systems to each system element. Inquass-Fmea searches the case base for similar entries. An entry is similar if it has the same or a more general type. The result is presented to the user in a list. The user has to choose the element that seems most appropriate to her or him. The contents of the chosen element are copied to the new system. Then the user may adapt the copied values to the current context. The search in the case base is supported by two user-de ned type hierarchies of systems and processes. The two type hierarchies are motivated by the fact that the physical structure of a system determines its potential failures and the associated actions. Each department of a company which uses Inquass-Fmea can de ne its own hierarchies. The support o ered, however, is limited. There is no function hierarchy, i.e., functions cannot be indexed and, consequently, cannot be searched for. It can also lead to an inconsistent and redundant naming of functions as there is no controlled vocabulary. Additionally, each type carries no other information besides its name. Name and the position of the type in the hierarchy only support the search in the case base. Flame II [11] aims at automating the FMEA process. The approach is based on an integration of functional modeling with qualitative reasoning. The functional modeling system reasons about what a system is supposed to do. The qualitative reasoning system reasons about the physical structure and the behaviour of circuits. Flame II provides sophisticated reasoning methods for reasoning about e ects of a failure mode, however, no other assistance is o ered. In particular, it is assumed that a suitable functional model is given. This is a major di erence to Wifa. For Wifa, the analysis of a system is the most important part of FMEA. Wifa concentrates on assisting the user during the analysis. Reasoning with the resulting model is less important. Wifa does not expect the nal model to be complete enough for reasoning of the kind Flame II provides and it can be questioned whether an engineer is able to provide such models, at least not for mechanical systems. Flame II employs a completely di erent approach because it is based on di erent premises. Flame II only considers electrical systems which are in general easier to analyze (cf. [12]): First, electrical systems have much less possible failure modes than mechanical systems. Potential failure modes of electrical systems are open circuit , short to ground , short to positive, and stalled . Second, for electrical circuits information about what the system is intended to do is available explicitly. This justi es the assumption that some kind of functional model is given. For mechanical systems, functional knowledge is usually not explicitly available and, thus, constructing a functional model constitutes a major task in mechanical design FMEA. Third, the e ects of mechanical failures are mostly harder to determine than the ones for electrical systems. For example, if a car loses a tire then the e ects of this failure can only be determined automatically if the model contains knowledge about physical laws (e.g., gravity). In Wifa, none of these restrictions are assumed. Wifa is not supposed to automate parts of the FMEA process but to provide knowledge-based assistance to the whole FMEA process, in particular the system analysis phase. 6 DISCUSSION This section evaluates the approach taken in Wifa, describes the current state of the project, and points out directions of further research. 6.1 Evaluation The unconstrained use of natural language and the lack of methodological guidelines have been identi ed as the fundamental problems of FMEA (cf. section 1). This often leads to incomplete descriptions of systems and functions, to inconsistent descriptions, and to FMEA knowledge that is hardly reusable. The core of Wifa is the taxonomic ordering of the most important technical concepts. In Wifa such a concept is called type. Each type is a pattern for describing speci c instances of that type. The taxonomies provide a controlled vocabulary that supports reuse of existing FMEAs because string-based search is replaced by a similarity-based search. The knowledge associated with a type allows for a more sophisticated similarity measure that takes context into account. Completeness and consistency checks are also based on types. For example, Wifa can check if each function participant of a function has been described. Furthermore, if taxonomies are standardized they can facilitate the communication between di erent companies (e.g., between supplier and manufacturer). Wifa can be considered as a new methodology for how to conduct FMEAs. It is this methodology that has to be imparted and which in our experience takes quite some time. However, Wifa has been designed in a way that allows it to be introduced in a stepwise manner. In the rst step a \plain" Wifa, i.e. a Wifa without a knowledge base, could be used to build system, function, and fault structures. This aids the comprehensibility of an FMEA. In the second step a user can assign each system element or ux one or more types from the system taxonomy or the ux taxonomy, respectively, and each function one type from the function taxonomy. This leads to an improved consistency of the description, better communication between the members of the FMEA team, and more elaborated search capabilities. In the last step the description of the function participants is added. This achieves a uniform description of all functions with the same type. Additionally, type restrictions for role values can be imposed and checked. It should be noted, however, that a knowledge-based system alone cannot be the remedy for the problems of conventional FMEA. It should not be attempted to automate the FMEA process completely. Neither should the user get the impression that the knowledge-based system \knows everything". Rather the system should act as a knowledgable assistant of the user. The system must be adapted to the users and their tasks and not vice versa. 6.2 Current state A rst Wifa prototype has been implemented. The prototype supports the de nition of system structures and fault trees and the automatic generation of function structures in two ways. First, it provides various tree editors for the handling of the system structure and the taxonomies. Second, while describing systems, functions, and failures, lists of possible attribute values are generated. Initial taxonomies for systems, functions, actions, processes and uxes have been developed and will be further extended and re ned based on practical experience in eld tests. Initial results are promising. A eld test of the prototype showed that the analysiswas more accurate and the resulting descriptions were more precise. The testing personsacknowledged that Wifa supports completeness, consistency, and accuracy of the analysis.However, the eld test also showed that both the contents of and the access routinesto the taxonomies are crucial; the user must be able to nd the concepts easily. Hence,the immediate next steps include a re nement of the concepts in the taxonomies and anenhancement of Wifa with user-friendly access tools.A shortcoming of Wifa is that the relationships among functions are described innatural language. Especially the result of a function, i.e. its purpose, is not explicitlymodelled. Thus, the automatic deduction of fault trees is hardly possible | a user mustbuild a fault tree mostly manually. Hence, Wifa introduces states [9]. In Wifa a staterepresents features of a system element, for example, \length 10 inches" or \diameterok". \discharged" or \broken" are also considered to be states. Various states can becombined to form preand post-conditions of functions, thus representing the behaviourof a system element. Based on this description Wifa is able to deduce possible fault treesautomatically as soon as the precondition of a function is violated. The suggested faulttrees can afterwards be edited by the user. It still has to be investigated, however, whetherthe additional bene ts of automating parts of Wifa outweigh the e ort for entering theadditional information. However, a discussion of this aspect would be beyond the scope ofthis paper.6.3 Further researchThe rst eld test showed that for practical success it is essential to hide the internalcomplexity of the Wifa system from the user. Wifa provides many options and it is noteasy for the user to choose an appropriate option for the subtask at hand. Developing anexplicit task model is a rst step to task-adapted user support and guidance.Furthermore, it is still an open question how product, design, and process FMEA areconnected to each other, i.e., what do the information ows look like. For example, everytechnical feature determined during design FMEA has to be manufactured. That meansthat these features are also part of the process FMEA.Another open question is how FMEA can be integrated with other quality managementmethods. Currently the integration of FMEA with quality function deployment (QFD) isexplored. The explicit representation of FMEA-relevant information (especially the de-scription of the functional structure) and the taxonomies provide a suitable backgroundbecause in QFD the users' requirements of a product are often expressed as functions andthe vocabulary to describe these functions is already held in the function taxonomy.Finally, the combination of functional modelling (as in FLAME II) and system mod-elling (as in Wifa) as a starting point for FMEA might be a step towards a more exibleapproach to FMEA. In an FMEA for an engine mechanical and electrical systems are con-sidered. Mechanical faults may cause electrical faults and vice versa. Wifa might be better suited for \mechanical FMEA" whereas FLAME II provides greater potential for \electri-cal FMEA". Combining these two approaches should yield better results than applying oneapproach for both types of FMEA.Although there remains a lot to be done, Wifa is a suitable starting point for furtherresearch and also for putting it into practice.ACKNOWLEDGMENTWifa was funded by Daimler-Benz AG, Robert Bosch GmbH, and AE Goetze GmbH.References[1] B.G. Dale and P. Shaw. Failure mode and e ects analysis in the U.K. motor industry|a state-of-the-art study. Quality and Reliability Engineering International, 6:179{188,1990.[2] Berthold Edenhofer and Albrecht Koster. Systemanalyse: Die Losung, FMEA optimalzu nutzen. Qualitat und Zuverlassigkeit, 36(12):699{704, Dezember 1991.[3] Agnar Aamodt and Enric Plaza. Case{based reasoning: Foundational issues, method-ological variations, and system approaches. AICOM, 7(1):39{59, 1994.[4] John A. Bateman. The theoretical status of ontologies in natural language process-ing. In Susanne Preu and Birte Schmitz, editors, Text Representation and DomainModelling { ideas from linguistics and AI, pages 50{99. KIT-Report 97, TechnischeUniversitat Berlin, May 1992. Papers from KIT-FASTWorkshop, Technical UniversityBerlin, October 9th{11th 1991.[5] Thomas R. Gruber. Toward principles for the design of ontologies used for knowl-edge sharing. In International Workshop on Formal Ontology, Padova, Italy, March1993. Also available as Technical Report KSL-93-04, Knowledge Systems Laboratory,Stanford University.[6] Herbert Birkhofer. Analyse und Synthese der Funktionen technischer Produkte. VDI{Verlag, Dusseldorf, Fortschrittberichte der VDI Zeitschriften edition, 1980.[7] K. Roth. Konstruieren mit Konstruktionskatalogen. Springer, Berlin, 1982.[8] Gerhard Pahl and Wolfgang Beitz. Konstruktionslehre. Springer, Berlin, 1986.[9] Y. Umeda, H. Takeda, T. Tomiyama, and H. Yoshikawa. Function, behaviour, andstructure. In J.S. Gero, editor, Applications of Arti cial Intelligence in EngineeringV, pages 177{193. Springer, Berlin, 1990.[10] Tilo Pfeifer, Jurgen Spiekermann, and Thomas Zenner. Konsequente Fehlervermei-dung durch FMEA. Qualitat und Zuverlassigkeit, 39:285{293, Marz 1994. [11] John E. Hunt, Chris J. Price, and Mark H. Lee. Automating the FMEA process.Journal of Intelligent Systems Engineering, pages 119{132, 1993.[12] John Hunt. Doing Mechanical Design FMEA. Jacquard Project Report JD038, 1992.Department of Computer Science, University College of Wales, Aberystwyth, Dyfed,SY23 3BZ, United Kingdom.